If it is an urgent security-related issues, does it require so many processes or time?

Redis will fix an urgent bug and release it immediately (like this one: redis/redis#10837),
or like other CVE fixes (security issues will also be released immediately (like all the fixes listed here: https://github.com/redis/redis/security).

If it is an urgent security-related issues, does it require so many processes or time?

The process itself is not related security. It is just a more formal procedure for releasing versions. Before that, it is unsure which commits the next release has, and whether it will be added to the release if some fixes is added to unstable while RM is releasing a version. This may cause conflicts.

BTW, in community management, I think we can learn a lot from Redis. But we do NOT follow Redis in everything, since it is not a non-commercial community.

The process itself is not related security. It is just a more formal procedure for releasing versions

yes, the process itself is not related security, i just want to start a thread that we can talk about it since i did not see we have a place that mention it. A serious security bug needs attention, when it is discovered or reported, we need to hide it until we find a fix and then publish it. Then it depends on the situation whether to release a version so that users can upgrade to prevent them from being attacked. Of course, it depends on PMCs or Apache way, i am not sure about it. Though kvrocks probably doesn't suffer many attacks these days.

Before that, it is unsure which commits the next release has, and whether it will be added to the release if some fixes is added to unstable while RM is releasing a version. This may cause conflicts.

i want to argue that we should (or we must) know which commits the next release will have. This should not be confirmed only when it is about to be released, but should be confirmed every time the PR is merged. And indeed, there will be a conflict since we sometimes will do a lot code cleanup (or refactor), but somehow it is also easy to slove the conflict if we have a clean git history.

i see we will select a RM to do the release, he will handle everything, such as doing the cherry-pick. Like i suggest in apache/kvrocks#1540 (comment), i think we should have a place that can contain some PRs (or commits) as a backlog. The new RM may not be familiar with commits that on the unstable branch since the new RM may not be involved in all PR reviews, or may not be familiar with certain parts of Kvrocks, it will be a hard job (or some important commits may be missed in the process).

i think we should, when a PR is submitted, we can confirm whether it is a feature or a bugfix. A bugfix, we can confirm which versions it will affect, and if we want to backport the fix to some versions, we should flag it (and write a release note if we will mention it in the release notes). This is something that the PR reviewer, or the person who merged the PR, or whatever, can do.

When we mark all the commits during the process, the cherry-pick will be easy to do, the new RC can easy to do the job and write a release notes, and then we ask PMCs (some commiters) to do the final review (Acks).

Of course, everything in the end depends on PMCs or Apache way. This is just a way that seems better to me (not just the Redis way)

A serious security bug needs attention, when it is discovered or reported, we need to hide it until we find a fix and then publish it.

For an ASF project, we have a security page (https://kvrocks.apache.org/community/security) for this situation.
However, we have not yet experienced this process, so we may not be proficient in it.

we should (or we must) know which commits the next release will have.

This is exactly the Release Proposal does.

i think we should have a place that can contain some PRs (or commits) as a backlog

That is a good idea, although may involves lots of work. I think we can do it after the current release.

Thanks all!

@enjoy-binbin Feel free to open a seperate discussion about other issues.